前言

前面的章節中講解了基本 Istio 功能如下

• Microservices、Service Mesh 基本概念
• Istio Traffic Management
  • 使用 Virtual Service、Destination Rule、Gateway 等 CRD 實現流量管理或是建立部署策略
• Istio Observability
  • Prometheus 蒐集 Metrics 資訊
  • Kiali 管理 Istio Service Mesh
  • Grafana 自製 Monitoring Dashboard
  • Jaeger 蒐集並呈現 Tracing 資訊
• Istio Scurity
• Argo Rollouts 結合 Istio 自動化完成部署策略

了解完這些基礎概念後，除了可以從 Day26 找尋有興趣的 Istio 功能深入研究之外，這裡也提供一些看完這系列文章後可以繼續精進自己的學習方向。

捨棄 Sidecar 的 Istio Ambient Mesh

Ambient Mesh 為筆者在寫本篇鐵人賽時 Istio 官方推出的新架構，是基於 Sidecarless 的全新 Service Mesh 模式，可以幫助我們降低成本、簡化操作並提升效能。

Ambient Mesh 的推出其實讓筆者有點猝不及防，因為本次鐵人賽是以 Sidecar 模式來撰寫的。

Istio 的傳統模式是用 Envoy 作為 Sidecar 部署到每一個 Pod 上，雖然能帶給我們彈性的流量規劃，但也就代表需要創造雙倍的 Container，除了造成硬體資源的浪費，並且因為 Sidecar 與 Application Container 放在同一個 Pod 上，若 Sidecar 需要更新就必須將整個 Pod 重啟，導致 Sidecar 對 Application 是有侵入性的。

而 Ambient Mesh 採用的是 Sidecarless 模式，會在每個節點上部署 Zero-trust Tunnel (ZTunnel) 元件，負責 Istio 的 Security 功能，但 ZTunnel 並不會對 L7 流量進行處理，若應用程式需要對 L7 進行管理，就會將流量交由 Waypoint Proxy，由於 Waypoint Proxy 是一般 Pod ，可以根據需求自由擴展，不僅能節省大量資源，也能降低 Service Mesh 對 Application 的侵入性。

Ambient Mesh Data Plane 架構圖，圖片取至 Istio Blog

Istio 官方有提供 Ambient Mesh 的幾篇介紹，並且提供安裝方式，有興趣的讀者可以點擊下方連接觀看。

Istio Blog - Get Started with Istio Ambient Mesh

Istio Blog - Introducing Ambient Mesh

Istio Blog - Ambient Mesh Security Deep Dive

不同的 Service Mesh 工具

在 CNCF Project 可以看到除了 Istio 之外還有許多 Service Mesh 開源工具，Istio 只是目前比較受歡迎的解決方案，難保之後不會被取代，尤其開源軟體發展迅速，學習其他 Service Mesh 工具也是在所難免。

近期有個討論度很高的技術叫 eBPF (Extended Berkeley Packet Filter)，可以從 Kernel 端過濾封包，而 Cilium 就是以 eBPF 技術打造的 Service Mesh 工具，可以在 Sidecarless 的模式下也能達成 Service Mesh 所需的功能，筆者認為是蠻值得學習的專案之一。

Cilium 架構圖，圖片取至 Cilium get-started

Cloud Native Trail Map

當然大家也可以在 Day1 介紹的 Cloud Native Trail Map 中繼續學習 Cloud Native 工具，本次系列文帶大家走完了 Observability & Analysis 以及 Service Proxy, Discovery & Mesh，接著可以試著了解 CNI (Container Network Interface)，學習 Kubernetes 內部的網路是如何運作的。

若是走完了 Cloud Native Trail Map，可以到 CNCF Landscape 找尋自己喜歡的主題，裡面有密密麻麻的開源專案絕對是學不完的。

鐵人賽心得

這是我第二次參加鐵人賽，這次選擇了比較困難的主題，因為自己還只是學生，並沒有像業界人士擁有許多實務經驗，在撰寫文章前需耗費大量時間學習技術，導致我拖到開賽當天才開始寫第一篇文章，開學後又遇到各種事情接踵而來，幾乎每天都要被小財神催稿，快截止了才按下發表文章結束痛苦的一天，就這樣持續奮戰了一個月，中間其實一度很想放棄，但最後還是撐完了。

切身體到會何謂『鐵人』賽，不僅考驗技術功底，更要有不能放假的決心

以前觀看鐵人賽文章時，大部分文章都以闡述概念為主，想跟著操作但內容有時都跳太快，卡在某個點通靈不出來就放棄了，所以在我撰寫的文章中，都會將每個步驟的指令、輸出結果都整理清楚，連 kubectl get、kubectl port-forward 等簡單的指令都不放過，目的除了讓讀者能了解每個指令的前因後果之外，也能依照教學實際動手實作。

有幾篇的 Lab 還是筆者自己設計的，用幾行指令即可完成，就是希望能以簡單的實作來講解複雜的 DevOps 概念

最後要感謝跟我一起參加鐵人賽的隊友，沒有團體賽的束縛可能中途就想棄賽，但結果是大家一起被小財神催稿 XD。我也對每個 DevOps 組的選手感到敬佩，畢竟開源工具發展很快，每年都有新功能釋出，撰寫之前肯定也要花不少功夫來學習。最後就是鼓勵已經快要學不動的你我，能夠在 DevOps 之路上繼續邁進！！